Role management

Dashboard

Users in each organisation are managed with RBAC. This is implemented using Casbin - for reference, please refer to roles.service.ts.

What is RBAC?

Role-Based Access Control, or RBAC, is a bit like a school system. Think of the school as a big building with many rooms - classrooms, a library, a staff room, and so on. Now, everyone in the school has a specific role. You have students, teachers, librarians, and the principal. Each role has its own set of permissions or access to certain rooms. This is the essence of RBAC - different roles have access to different resources.

Let's dive a bit deeper. A student can access classrooms and the library, but they can't go into the staff room. A teacher, on the other hand, can access the staff room, classrooms, and the library. The principal has the highest level of access, including areas like the school records room, which others can't access. This is how RBAC works - each role has fixed access to certain groups of resources.

Now, imagine there's a main school and a smaller, subsidiary school. When a new student or teacher joins the main school, they have the same access rights as others in the main school. They can access the same rooms and use the same resources. This is similar to how users registered on the main organisation in an RBAC system have the same resource rights as the suborganisation.

But what happens when a student or teacher joins the smaller, subsidiary school? Well, they only get the access rights of the subsidiary school. They can't access the rooms or use the resources of the main school. This is like how users in the suborganisation in an RBAC system don't have access rights to the main organisation.

So, in essence, RBAC is like the rules of our school. It helps us decide who can do what and where they can go. It's important because it keeps our school safe and organized, ensuring that everyone knows their role and what they can and can't do.

API access

In our system, the access to API resources is governed by an Access Control List (ACL), which is implemented using a tool called Casbin. This tool helps us manage who can access what, ensuring that each user only has access to the resources they need.

To facilitate this, we generate secret keys that are allocated the appropriate rights. These keys act like special passes, granting the holder the access rights associated with the key. It's important to note that these keys are only visible in plaintext once, at the time of generation.

The reason for this is to protect liability. If a key is lost, it cannot be retrieved by any party. This ensures that if a key falls into the wrong hands, it can't be used to gain unauthorized access.

To further enhance security, these keys are stored in our database using a unidirectional hash. This means that even the system administrators can't read the keys. They're securely stored and protected from any potential breaches.

Finally, our system allows for the creation of multiple secret keys, each with varying levels of access. This means that different users can have different access rights, depending on their needs. And if a key is no longer needed, it can be easily deleted from the system.